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User Datagram Protocol 


Introduction 


This User Datagram Protocol (UDP) is defined to make available a 
datagram mode of packet-switched computer communication in the 
environment of an interconnected set of computer networks. This 
protocol assumes that the Internet Protocol (IP) [1] is used as the 
underlying protocol. 


This protocol provides a procedure for application programs to send 
messages to other programs with a minimum of protocol mechanism. The 
protocol is transaction oriented, and delivery and duplicate protection 
are not guaranteed. Applications requiring ordered reliable delivery of 


streams of data should use the Transmission Control Protocol (TCP) [2]. 
Format 

0 7 8 15 16 23 24 cal 

+-------- 4+-------- +-------- +-------- + 

| Source | Destination | 

| Port | Port | 

+-------- +-------- 4+-------- +-------- + 

| Length | Checksum | 

+-------- +-------- +-------- +-------- + 


| data octets 


User Datagram Header Format 


Fields 


Source Port is an optional field, when meaningful, it indicates the port 
of the sending process, and may be assumed to be the port to which a 
reply should be addressed in the absence of any other information. If 
not used, a value of zero is inserted. 
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Fields 


Destination Port has a meaning within the context of a particular 
internet destination address. 


Length is the length in octets of this user datagram including this 


header and the data. (This means the minimum value of the length is 
eight.) 


Checksum is the 16-bit one’s complement of the one’s complement sum of a 
pseudo header of information from the IP header, the UDP header, and the 
data, padded with zero octets at the end (if necessary) to make a 
multiple of two octets. 


The pseudo header conceptually prefixed to the UDP header contains the 
source address, the destination address, the protocol, and the UDP 
length. This information gives protection against misrouted datagrams. 
This checksum procedure is the same as is used in TCP. 


0 7 8 15 16 23 24 31 
+-------- +-------- +-------- +-------- + 
| source address | 
+-------- +-------- +-------- +-------- + 
| destination address | 
+-------- +-------- +-------- +-------- + 
| zero |protocol| UDP length | 
+-------- +-------- +-------- +-------- + 


If the computed checksum is zero, it is transmitted as all ones (the 
equivalent in one’s complement arithmetic). An all zero transmitted 
checksum value means that the transmitter generated no checksum (for 
debugging or for higher level protocols that don’t care). 


User Interface 


A user interface should allow 


the creation of new receive ports, 


receive operations on the receive ports that return the data octets 
and an indication of source port and source address, 


and an operation that allows a datagram to be sent, specifying the 
data, source and destination ports and addresses to be sent. 
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IP Interface 


The UDP module must be able to determine the source and destination 
internet addresses and the protocol field from the internet header. One 
possible UDP/IP interface would return the whole internet datagram 
including all of the internet header in response to a receive operation. 
Such an interface would also allow the UDP to pass a full internet 
datagram complete with header to the IP to send. The IP would verify 
certain fields for consistency and compute the internet header checksum. 


Protocol Application 


The major uses of this protocol is the Internet Name Server [3], and the 
Trivial File Transfer [4]. 


Protocol Number 


This is protocol 17 (21 octal) when used in the Internet Protocol. 
Other protocol numbers are listed in [5]. 
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